The present invention generally relates to techniques for hiding peer devices in a computer bus and, more particularly, to a circuit and method for hiding peer devices in a PCI (peripheral component interconnect) bus to avoid conflicts of such devices with a host system.
It is known that requirements of high performance and reliable networks have led to advances in disk drives and in disk subsystem architectures. Disk drive storage sizes have increased, access times have decreased, and data transfer rates have increased. Processing capabilities of personal computers and workstations have also advanced. As more clients are added to a given network and the processing capability of those clients increase, there is a continuing push to further enhance the performance of disk subsystems servicing that network.
In response to the need for reliable and inexpensive disk drive subsystems, redundant array of independent disk (RAID) architectures have been developed. RAID architectures can provide error detection and duplicate storage of information on a disk drive subsystem in the event one or more disk drives in the disk drive subsystem fail. Some of the advantages provided by RAID architectures have been higher data transfer rates, increased disk capacity, higher input/output (I/O) rates, and faster data access. Depending upon which level of RAID architecture was implemented, various features, such as disk striping, mirroring, parity checking, or combinations thereof, have been used. These RAID implementations and others are well known to those of ordinary skill in the art.
Some known RAID implementations have included in a pluggable add-in card devices such as an I/O processor loaded with suitable firmware to perform the RAID functionality, and an I/O controller coupled to a respective disk drive. In one known implementation, referred to as Zero Channel RAID (ZCR), the RAID card was simplified to include just the I/O processor and not the I/O controller. This implementation conveniently uses the I/O controller embedded on the motherboard of the host computer. Thus, this ZCR implementation reduces the cost of the RAID card since there is no need to duplicate the I/O controller circuitry provided in the motherboard of the host computer.
At least two techniques are known that have attempted to avoid conflicts that could arise when more than two control devices, such as the host system and the add-in RAID processor, try to assert control of another device, such as the embedded I/O controller. In one of such techniques, there is no attempt to hide any of the devices sharing a common bus, such as a PCI bus, from one another. Thus, whenever the host system needs to communicate with any target device, such as the embedded I/O controller, and another device, such as the add-in RAID processor, needs to communicate with that same target device, there has to be a higher level arbiter for managing communication between the RAID processor and the host system to negotiate which device is going to control the target device. The operating system supplied by the computer manufacturer somehow would have to understand how to communicate and negotiate such transaction regardless of the specific firmware and hardware of the add-in devices. It will be appreciated that this task is very complicated since such hardware and firmware may vary from vendor to vendor. Further, even if the add-in devices were supplied by a single vendor, due to the rapidly changing nature of computer technology, the hardware and firmware of such add-in devices are likely to change over time due to evolutionary changes. Thus, it is very burdensome for any supplier of operating systems, e.g., Microsoft, to support all the different mechanisms for negotiating that control.
Another technique has provided circuitry on the motherboard to intermittently hide the devices from one another. For example, when the RAID processor needs to communicate with the I/O controller, the RAID processor may send a signal to make visible or “unhide” the I/O controller. The RAID processor would run for a relatively short period of time during which communication with the I/O controller would occur. The RAID processor would then send a signal to conceal or “hide” the I/O controller. The reason for such intermittent “hiding” and “unhiding” actions is that one would want to avoid the host system to detect the presence of the I/O controller. One drawback of this technique is that prior to the time the RAID controller turns on the “unhide” signal and communicates with the I/O controller, that RAID controller has to initially request for a grant of the bus and there may be conditions where such bus grant may be denied by the host system. For example, the host system may require access to the bus at the same time. And since the host system generally has priority over control of the bus, the host may have initial access to the bus. In this scenario, once the “unhide” signal turns on, the operating system of the host would detect the presence of the I/O controller and would undesirably assume control of that controller. The fact remains that under this other technique there is a window of opportunity for conflicts between the host and the add-in RAID processor.
In view of the foregoing difficulties, it would be desirable to provide a technique that overcomes such difficulties. For example, it would be desirable that when the add-in card is plugged into an expansion slot, the I/O controller embedded in the motherboard be concealed from the operating system and such I/O controller becomes visible only to the RAID processor on the add-in card.